Updated the PR based on further discussion in #441 about what happens when a 0-length read and write rendezvous. In the previous iteration, both were notified; with this update, only the writer is notified, since this ends up being what you want if there is going to be buffering (as mentioned in the PR and also this comment).

cc @dicej on this as it relates to our discussion this morning. It looks like the wasip3-prototyping branch doesn't implement the spec as-is as 0-length reads/writes aren't trapped, and it also hasn't been updated to take this PR into account either. Basically I think wasip3-prototyping is an ambiguous state right now as to what 0-length reads/writes mean.

Also question for you @lukewagner. The topic of 0-length reads/writes have come up in the context of figuring out what the result of an async stream operation is. Specifically I was attempting to model the result of a stream operation as a tri-state value of either (a) completed with N items, (b) closed, or (c) cancelled. Given the way the return codes map here though is it correct to say that if you cancel a 0-length operation there's no way to figure out what happened as a result? The canonical ABI code returned will be 0, maybe eventually, and that's ambiguous whether the read/write was cancelled or "completed"?

You're right, as currently written, after a BLOCKED cancellation, the event tuple will be the same as-if the operation completed. I wasn't sure whether this was a problem due to the fact that the cancellation comes from within the same component that receives the event, but I guess in the BLOCKED case there is a race and so this could actually lose useful information. I already think we need to slightly change the packed result of a stream operation to have a 4-bit "what happened" code separate from the 28-bit optional "payload", and so this could be fit in with that change.